| |||||||||
This section discusses the Authenticator module. Section contents: | |||||||||
![]() |
|||||||||
Introduction to the Authenticator module | |||||||||
The objective of the process of authentication is to confirm or deny that an entity is real or genuine. Authentication is most commonly used to confirm or deny identity,
authenticity and integrity. An example of when identity authentication is required is when receiving an email. Provided that the content of the email does not raise immediate
doubts, most people authenticate the sender implicitly by comparing the email address of the sender with the email address that they expect to see if the email was indeed sent
by the authentic sender. However, this is the same as authenticating the sender of a conventional letter by the return name and address on the back of the envelope. It is flawed
logic. Obviously, one can place whatever return address they like on a conventional letter. The underlying erroneous assumption that many people make is that the declared email
sender is always the mail box from where the email was sent. The reasons for this assumption may be routed in the fact that most people simply use mailing software which hides
the internal operations of the mail server, and so people assume that it is somehow an automatic and secure process void of external inferences. Therefore, it is important to
authenticate emails containing private or sensitive content to a sufficient degree. A simple, effective step-by-step mechanism on how to exchange information online safely is
described in the Exact Steps to Exchange Emails
Safely protocol. The protective power of authenticity verification can be also used to confirm that a file was created by the entity that claims to have done so. For example, when installing software on Windows Vista and above, the user is shown a window which either confirms the authenticity of the installation package or states that the software origin cannot be established i.e. authenticated. An excellent example of direct benefits brought about by authentication is when it is employed to digitally sign the testimonials placed on a website. This allows the visitors of the website to automatically verify the testimonials with the referee and be sure that they are authentic and genuine, which raises the level of trust in the website multiple times. This simple but important mechanism is explained step-by-step in the How to Make Your Website Trusted protocol. There are other cases when it is important to establish the authenticity of a data file or document. Sometimes the authentication process may deal with establishing the integrity of a file, rather than its origin. For example, that a file has not been corrupted by errors during transmission. The authentication process is simple and is generally some variation of the following three steps:
|
|||||||||
The Authenticator module functionalities | |||||||||
|
|||||||||
Authentication Principles | |||||||||
Definitions and Naming | |||||||||
In order to simplify this discussion we will introduce the following definitions: Definition: Authenticator is the entity that uses the process of authentication to verify the authenticity of another entity. Definition: Authenticatee is the entity whose authenticity (or identity) is being verified by the authenticator. Definition: Private Key is a file with special content produced by a special algorithm which is used in certain authentication and encryption processes. You can generate a new private key using Act On File at any time. Definition: Public Key is a file produced from a particular private key and is also used in the same processes of authentication and encryption as its complement private key. Note: Although the authenticatee role may seem to be passive, the digital authentication process requires the authenticatee to create and appropriately supply a reference. Note: There are different types of public and private key pairs, respectively used for authentication and encryption. In this document we discuss authentication. |
|||||||||
Create and Supply Reference | |||||||||
The first thing that needs to be done before an Authenticator is able to authenticate the authenticatee is for the authenticatee to create an appropriate reference and supply it to anyone
who would later authenticate the authenticatee using it. Most commonly the reference is one or more of the following:
Act On File does not work with digital certificates since, as explained earlier, they bring large overheads and limited benefits, although they do have their place when a direct authentic channel cannot be established but indirect is possible. However, Act On File accentuates on the direct use of authentication using a public and private key pair, for which the existence of a direct authentic channel between the entities is necessary. Establishing a direct authentic channel can be very simple, but in some specific cases it may not be possible. Usually, but not always, if an indirect authentic channel does exist, then a direct authentic channel may also exist. This is especially true if at least one of the sides is able to accommodate some flexibility. Establishing an authentic channel simply consists of finding a means to transfer the reference from the authenticatee to the authenticator in a way that the authenticator is certain that the authenticatee supplied the reference (and not an imposter) and the reference has not been in any way corrupted. There is always a degree in that certainty which is usually implicitly adjusted to reflect the required level of security. Some of the multiple possible examples include:
|
|||||||||
Sign Entity - Digital Signatures | |||||||||
The digital signature of a file ("signed file") is another file which is derived from it using a special algorithm and a private key. The signature is a small file with a
typically constant size dependent on the algorithm and the size of the key that were used in producing it. The idea is that due to the nature of the used algorithms and private key, there is a unique bond between the
signed and the signature files. This bond could be verified only with the original private key used to produce the signature, or with its complementing public key. Thus, if the recipient of a message receives a data
file and its signature, then using the public key (reference) of the sender (which they obtained through an authentic channel as discussed above), they can verify whether or not the file is authentic and its integrity is intact. Using the Sign Files functionality of Act On File, one first creates and saves a public and private key pair. If they already have a private key, they can simply import it. They then proceed to sign the selected files by using the Sign Files functionality, generating the signature files. Depending on the destination mode, the signatures may be deposited in an appropriate location on a drive or be appended to each respective signed file. The signed files and signatures are then ready to be transferred to their destinations. Once transferred, the recipients can then use the reference that they were given (the public key complement to the private key used in the production of the signatures) to verify the origin and integrity of the signed files. Any change in a signed file or its signature will result in a negative or failed result from the verification process using the reference. |
|||||||||
Verify Entity | |||||||||
To verify a file, one needs to have the file, its digital signature and the public key complement to the private key used for generating the signature. Use the Verify Signatures
functionality of the Authenticator module of Act On File to verify the authenticity (origin and integrity) of the authenticated file. In practice, this process can be used to authenticate emails by signing files and attaching them and their signatures (appended to the original file or as separate attachments) to the message. The message recipient then authenticates the files using the public key of the sender (perhaps available for download from their website or otherwise authentically supplied). Note that this process authenticates the attachments and not the email as the attached authentic file and its signature may have been intercepted and misused by imposters. To authenticate the actual message, the signature must either be included as text within the body of the message, or be added to the end of it. Besides email authentication, there are many other scenarios and cases where authentication using the above principles and mechanisms could easily and successfully be used ensure the security, safety and smooth performance of many systems. For example, one may authenticate legal entities, people, electronic and digital systems, messengers, data stored on media and other devices, data communication etc. |